Mapping of BusObjects in WS-AppServer |
|
- XML - Representation of the BusObject is through a SOAP request and response
- DB - Representation of the BusObject stored in the database (RDBMS or other persistent stores)
- Java - Representation of the BusObject in a Java wrapper around an XML document
During data exchange, a BusObject may pass through a combination of these representations (XML to Java, Java to DB, and so on) before it is finally persisted. The following table provides a quick reference to the various combinations that are used by WS-AppServer.Combination Description XML to Java When an object is received through a SOAP request, WS-AppServer creates a BusObject and places the XML of the SOAP request in it. While doing this, WS-AppServer reads the class registry and maps the incoming XML to the corresponding Java class. Java to DB The Java class is mapped to XML so that it is understood by XQY. XQY then transfers the content of the XML to the relevant database tables and updates them. The Java to DB mapping usually maps custom classes to standard classes, and invokes insert, update, or delete operations on those standard classes which persist the BusObject to the database. DB to Java Information to be passed from the database to Java is either generated in the base class or is implemented by the developer in the extension class. To transform DB information into a Java class, XQY takes a query as input, and produces the output as XML documents. The query object creates the BusObject based on the XQY output. Java to XML When a Java object is used in a SOAP response, WS-AppServer refers the BusObject in store, retrieves its XML representation, and sends it in the response.
Mapping Names to Database
If an object of typeStateBusObjectis inserted or updated into the database, then the name of the class is mapped to the name of the table. Similarly, the name of an attribute is mapped to the name of a column in the table. By default, the names are exactly the same.
WS-AppServer uses a mapping strategy to map a class name to a table name and map an attribute name to a column name. A mapping strategy is implemented in an object that implements IMapClassStrategy and IMapAttributeStrategy .
WS-AppServer has a number of standard mapping strategies, both for class mapping and attribute mapping.
| Mapping Level | Types | Description |
|---|---|---|
| Class to Table | TrivialStrategy | Attribute names are not mapped. However, class to table name mapping can be specified. This is the default mapping strategy forStateBusObject. |
| DefaultStrategy | Maps class name to table name. This strategy can be configured usingIMapAttributeStrategyorDefaultAttributeStrategy | |
| Attribute to Column | NameMappingStrategy | Maps attribute name to column name. This strategy is configured with attribute-column name pairs and is used in situations where column names differ from attribute names. |
| DefaultAttributeStrategy | Maps attribute name to column name. This strategy usesAttributeInfoto determine the mapping. |
Besides these standard mapping strategies, you can also implement your custom mapping strategy.
CUSTOM MAPPING
A custom mapping can be defined by implementing a custom mapping strategy, probably in combination with one of the standard strategies. To make use of custom mapping, the custom mapping strategy must be registered with the class. This registration is done in the method customizeClassInfo as shown in the code.
/**
* Define the mapping strategy
*/
public static void customizeClassInfo(CustClassInfo ci)
{
ci.setMappingStrategy(new MyMappingStrategy(ci));
}
The following attached files containing the Java code provide an example of how custom mapping is implemented.